home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19981211-19990422 / 000346_news@watsun.cc.columbia.edu _Thu Mar 11 18:37:03 1999.msg < prev    next >
Internet Message Format  |  1999-04-21  |  3KB
  1. Return-Path: <news@watsun.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA17065
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 11 Mar 1999 18:37:02 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA18008
  7.     for kermit.misc@watsun.cc.columbia.edu; Thu, 11 Mar 1999 18:20:26 -0500 (EST)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: jwmanly+news@amherst.edu
  10. Subject: Re: C-Kermit Scripting using INPUT and LOG SESSION
  11. Date: 11 Mar 1999 18:09:45 -0500
  12. Organization: Amherst College
  13. Message-ID: <36e84d39.0@amhnt2.amherst.edu>
  14. To: kermit.misc@mailrelay2.cc.columbia.edu
  15.  
  16. Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
  17. : : Why the necessity for the INPUT line? I assume it is to force
  18. : : C-Kermit to somehow "consume" or "process" the information, but is there
  19. : : any other, cleaner way to do that?
  20. : : 
  21. : No.  You have to think of INPUT as an analog for your eyes and brain.
  22. : If you were in CONNECT mode, you'd watch the stuff coming in, and eventually
  23. : you would see something that tells you it's done.  No INPUT, no eyes (and
  24. : no brain :-)
  25.  
  26. Got it.  So how does LOG SESSION fit into this?  That is, at what point does
  27. material coming in get written to the log file -- when it hits the DEVICE
  28. buffer, or when it gets moved from that buffer to the INPUT buffer?
  29.  
  30. : : Final question: notice how I put that "INPUT 10 </html>" command at the end
  31. : : of the script to flush out whatever other data comes back from the remote
  32. : : server following the part that I am intersted in?  If I don't do this, when
  33. : : I hit the EXIT at the end of the script (even though it follows the HANGUP
  34. : : command), I get the "There may still be a connection open, OK to exit?"
  35. : : message when the script finishes.  I assume this is because there is
  36. : : "unconsumed" data in the buffer.
  37. : :
  38. : It's because the connection is still open, just like it says.  The server
  39. : closes the connection after all the data it sent has been acknowledged
  40. : (at the TCP level).
  41.  
  42. And it's not acknowledged until it has been moved to the INPUT buffer by an
  43. INPUT command?  Got it.  This would seem to suggest some usefulness to some
  44. kind of FLUSH or PAUSE-WHILE-FLUSHING command -- you know, pause for 2 seconds
  45. and discard anything that comes in during that time.  I've sometimes wanted to
  46. do that in the middle of a script, and doing a bogus "INPUT 2 XXXXX" seems a 
  47. bit kludgy.
  48.  
  49. While we're at it, some TELNET clients have a function (usually bound to a key)
  50. that does a "send mark and then flush to mark" function -- often called abort
  51. output.  Does Kermit have anything like this that can be used from a script?
  52.  
  53. : : How do I tell Kermit to drop the
  54. : : connection regardless of whether there is anything left in the buffer or
  55. : : not, even if data is still streaming in?
  56. : : 
  57. : Like it says in the book:
  58.  
  59. :   SET EXIT WARNING OFF
  60.  
  61. Hmmm.  So HANGUP just tells the other end to close down, but doesn't actually
  62. close the connection.  There's no straightforward way to tell Kermit to
  63. tell the other side to close down and wait for some number of seconds to see
  64. if the TCP connection is actually closed by the remote side?
  65.  
  66. -- John W. Manly  <jwmanly@amherst.edu>  (Amherst College)